Robot-as-a-Service: from Cloud to Peering Technologies
Service provider
サービス指向
変化への適応性
business layer ビジネス要件、要求
application APIなど、サービス
processing 処理
transport 通信など
perception 知覚
上層から並べ直したが、細かくは、論文見ないとわからない
以上から↓提案
https://gyazo.com/45f3e9cef6cdcec4a9cba96507c8b11b
多分、ここの図参考にしたんだと思う
Promisee (API叩く側、サービスを利用する側)
(義務としての)責任負債?
分散型ストレージに責任、appの配置?
オープンで分散する必要は、あるのか?
コンソーシアムは駄目なの?
Provider
クライアントはどこに載せるの?
今回IPFS PubSub トピックは、Lighthouse ENS名に従って設定されてる
他のはどうか?あ
/hogeは、AIRAの既存サービス、APIのようなもの(Node?)
特徴
中央のマネジメントシステムを作らない
メリット
computerリソースの節約?
more robust 障害に強い
利点?
他の参考